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Sir: 

This Appeal Brief is submitted in support of the Notice of Appeal filed May 
2, 201 1, wherein the Appellants appeal from the Examiner's rejection of claims 14, 
21, 28, and 35-53. 



I. REAL PARTY IN INTEREST 

The subject patent application (the "Application") has been assigned to 
International Business Machines Corporation by assignment recorded on February 
7, 2007, at Reel 018862, Frame 0231. 

II. RELATED APPEALS AND INTERFERENCES 

Appellants are unaware of any related appeals and interferences. 

III. STATUS OF CLAIMS 

Claims 14, 21, 28, and 35-53 are pending in the Application and have been 
rejected at least twice. It is from the multiple rejections of claims 14, 21, 28, and 
35-53 that this Appeal is taken. Claims 1-13, 15-20, 22-27, and 29-34 have been 
cancelled. 

IV. STATUS OF AMENDMENTS 

No claims were amended after the final official action dated January 31, 
201 1 (the "Final Office Action"). 



V. SUMMARY OF CLAIMED SUBJECT MATTER 



With respect to claim 14, a computer- implemented method for processing 
contract data associated with services to be provided via a network in an 
infrastructure, in which a plurality of binding contracts exists between a service 
provider and a service requestor for services having a respective number of service 
specifications, has been claimed. (Page 17, lines 26-28) The method includes 
creating the contract data comprising contract selection parameters for 
subsequently selecting at least one service contract out of the plurality of contracts. 
(Page 25, lines 22-29) The method also includes including the contract data into a 
request for the service. (Page 25, lines 1-5) The method further includes issuing, 
via the network, the request for the service. (Page 25, lines 6-8) Finally, the 
method includes receiving, via the network, the service according to a selection of 
the at least one service contract based upon the contract selection parameters. 
(Page 25, line 19) 

With respect to claim 21, a service requester computer server hardware 
system for processing contract data associated with services to be provided via a 
network in an infrastructure in which a plurality of binding contracts exists 
between a service provider and a service requestor for services having a respective 
number of service specifications has been claimed. (Page 17, lines 26-28) The 
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system includes at least one processor, wherein the at least one processor 
configured for creating the contract data comprising contract selection parameters 
for subsequently selecting at least one service contract out of said plurality of 
contracts (page 25, lines 22-29); including the contract data into a request for said 
service (page 25, lines 1-5); issuing the request for the service via network (page 
25, lines 6-8); and receiving the service according to a selection of the at least one 
service contract based upon the contract selection parameters (page 25, line 19). 

With respect to claim 28, a computer usable tangible medium having 
computer readable instructions embodied therein for processing contract data 
associated with services to be provided via a network in an infrastructure in which 
a plurality of binding contracts exists between a service provider and a service 
requestor for services having a respective number of service specifications has 
been claimed. (Page 17, lines 26-28) The computer readable instructions, when 
executed on a computer system, causing the computer system to perform the 
operations comprising: creating the contract data comprising contract selection 
parameters for subsequently selecting at least one service contract out of the 
plurality of contracts (page 25, lines 22-29); including the contract data into a 
request for the service (page 25, lines 1-5); issuing, via the network, the request for 
the service (page 25, lines 6-8); and receiving, via the network, the service 
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according to a selection of the at least one service contract based upon the contract 
selection parameters (page 25, line 19). 

With respect to claim 35, a computer-implemented method for processing 
contract data associated with services to be provided via a network in an 
infrastructure, in which a plurality of binding contracts exists between a service 
provider and a service requestor for services having a respective number of service 
specifications has been claimed. (Page 17, lines 26-28) The method includes 
receiving, via the network, the contract data included in a request with which the 
service is requested. (Page 25, lines 9-11) The contract data includes contract 
selection parameters for selecting at least one service contract out of the plurality 
of contracts. (Page 25, lines 22-29) The method also includes evaluating the 
contract selection parameters. (Page 25, lines 11-12) The method further includes 
selecting one particular contract according to the evaluation and further selection 
logic. (Page 25, lines 13-16) Finally, the method includes providing, via the 
network, the service according to the contract. (Page 25, lines 18-19) 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The rejection of claims 14, 21, 28, 35-36, 40, 42, 46, 48, and 52 under 35 
U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,148,290 to Dan et al. 
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(Dan) in view of U.S. Patent Application Publication No. 2002/0178120 by Reid et 
al. (Reid). 

The rejection of claims 37-39, 43-45, and 49-50 under 35 U.S.C. § 103(a) as 
being unpatentable over Dan in view of Reid and fiirther in view of SOAP ("SOAP 
Version 1.2 part 1: Messaging Framework", W3C, 2 October 2001). 

The rejection of claims 41, 47, and 53 under 35 U.S.C. § 103(a) as being 
unpatentable over Dan in view of Reid and further in view of U.S. Patent 
Application Publication No. 2005/01981 1 1 by Lamb et al. (Lamb). 

VII. THE ARGUMENT 

The rejection of claims 14, 21, 28, 
35-36, 40, 42, 46, 48, and 52 Under 35 U.S.C. § 103 

Claims 14, 21, 28, 35-36, 40, 42, 46, 48, and 52 have been rejected 35 U.S.C. 
§ 103(a) as being unpatentable over Dan in view of Reid. For the convenience of the 
Honorable Board, claims 36 and 40 stand or fall together with independent claim 14; 
claims 42 and 46 stand or fall together with independent claim 21; and claims 48 and 
52 stand or fall together with independent claim 28. 

With respect to the Examiner's determination of obviousness, it is noted that 
the law of obviousness under 35 U.S.C. § 103(a) and the Examination Guidelines 
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set forth in M.P.E.P. 2141 (specifically, rationale (A) of M.P.E.P. 2141) require 
Examiner to locate all claimed teachings in the combination of cited references. 



Specifically, exemplary claim 14 sets forth a computer- implemented method 

for processing contract data associated with services to be provided via a network 

in an infrastructure, in which a plurality of binding contracts exists between a 

service provider and a service requestor for services having a respective number of 

service specifications. For the convenience of the Honorable Board, the entirety of 

claim 14 has been reproduced herein as follows: 

14. A computer-implemented method for processing contract data associated 
with services to be provided via a network in an infrastructure, in which a 
plurality of binding contracts exists between a service provider and a service 
requestor for services having a respective number of service specifications, the 
method comprising: 

creating said contract data comprising contract selection parameters for 
subsequently selecting at least one service contract out of said plurality of 
contracts; 

including said contract data into a request for said service; 
issuing, via the network, said request for said service; and 
receiving, via the network, the service according to a selection of the at 
least one service contract based upon the contract selection parameters. 



Integral to claim 14 (and also claims 21, 28, and 35) is the inclusion of the 
contract data that includes contract selection parameters for subsequently selecting 
at least one service contract out of the plurality of contracts into a request for the 
service. Appellants submit that at least this limitation is not disclosed by any of 
the cited references or any combination thereof. 
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Notwithstanding, in rejecting this limitation, Examiner stated on page 3 of 



the Final Office Action the following: 

including said contract data into a request for said service (col. 7, line 
24 thru col. 8, lines 20; "in step 720, the contract enforcement code is 
generated and integrated with the service implementation code for enabling 
actual runtime invocation. FIG. 8 illustrates the use of the contract 
enforcement code during runtime, according to an embodiment of the present 
invention. In step 800, an external request (or message, or document) arrives 
at a particular enforcement code component. The contract enforcement code 
then determines, based on the incorporated rules of interaction, the current 
interaction state and the interaction history of the service (e.g., requests and 
responses received), and whether such a request (or message, or document) is 
acceptable from the specific requester as per the rules of interaction,"); 



For the convenience of the Honorable Board, col. 7, line 24 to col. 8, line 20 of 
Dan, cited by Examiner, has been reproduced herein as follows: 

FIG. 7 illustrates the development of the contract enforcement code and its 

integration with a service application, according to an embodiment of the present 
invention. First, in step 701, the parties create a joint formal document, referred to 
as the service contract. As indicated hereinabove, the service contract also can be 
created by a subset of the parties. The elements of one embodiment of the contract 
are detailed hereinbelow with regard to FIG. 9. The service contract is then 
registered, in step 710, by all interacting parties in their respective servers. This 
registration preferably includes storing of a service contract identification number, 
information regarding the service contract and the service contract itself . In a 
preferred embodiment, a tool is available for automatically generating 
enforcement code. The registration aids in this automatic generation of the parties' 
role-specific contract enforcement code. In the absence of such a tool, however, 
the code is written by hand, capturing the rules of interaction specified in the 
contract. The code also contains information on the local application, such as how 
to invoke the local application, what specific method to call upon receiving a 
specific message, request or document. Finally, in step 720, the contract 
enforcement code is generated and integrated with the service implementation 
code for enabling actual runtime invocation . 
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FIG. 8 illustrates the use of the contract enforcement code during runtime, 
according to an embodiment of the present invention. In step 800, an external 
request (or message, or document) arrives at a particular enforcement code 
component. The contract enforcement code then determines, based on the 
incorporated rules of interaction, the current interaction state and the interaction 
history of the service (e.g., requests and responses received), and whether such a 
request (or message, or document) is acceptable from the specific requester as per 
the rules of interaction , in step SlO.If the request is determined to be acceptable, 
the contract enforcement code invokes, in step 820, an appropriate application 
method (or program). After the appropriate service implementation logic is 
executed to provide this service, a response may be generated. Note that the 
execution may be synchronous or asynchronous with the client request. The 
service logic may be a simple program or a multi-step execution synchronously or 
asynchronously involving business rules and internal methods where the business 
rules specify how the next method or execution step is to be selected. That is, the 
service logic may be adapted to support long-running interactions or sequences of 
interactions which are timed apart. For example, the logic can support a situation 
in which a customer requests a reservation with a hotel service provider and 
requests a cancellation days later. In this example, the service contract of the 
present invention will capture the rules of interaction for such timed-apart 
interactions. The service logic may also make requests on other partners via other 
service contract enforcement code or via the same contract enforcement code. 
Hence, if there is a response to the original request, the service implementation 
logic sends the response to the particular contract enforcement code, in step 830. 
The confract enforcement code may add this response to the history of 
interactions, before sending it back to the original requester. Finally, if the 
original request is determined to be unacceptable, in step 810, the requester may 
be notified of this rejection in step 840. The contract enforcement code may also 
specify independent action to be taken by a partner in the absence of a response 
from another partner within a pre-specified time. 



Thus, Dan teaches the development of the contract enforcement code and its 
integration with a service application. 



Of note, an important aspect of the Appellants' claimed invention is to 
include contract selection parameters into the service request (particularly into the 
query string of the endpoint address of the request) so that the requestor can have 
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influence on the contract selection. Clearly, Dan as reproduced above does not 
disclose using the contract selection parameters to select at least one service 
contract out of a plurality of contracts. Rather, Dan concerns the enforcement of 
one contract, not the selection among multiple contracts. Dan further does not 
disclose the inclusion of the contract selection parameters into a request. Reid 
does not cure the deficiency of Dan. Reid discloses a database that may be 
searched for particular agreements based on several parameters. However, Reid 
does not disclose that the parameters are included in the service request. 

Since the Examiner has not located all claimed teachings in the combination 
of cited references, Appellants submit that Examiner has not established a prima 
facie case of obviousness under the law and Appellants solicit the Honorable 
Board to reverse the rejections set forth thereby. 

The rejection of claims 37-39, 43-45, and 49-50 Under 35 U.S.C. § 103 

For the convenience of the Honorable Board, claims 37-39 stand or fall 
together with independent claim 14; claims 43-45 stand or fall together with 
independent claim 21; and claims 49-50 stand or fall together with independent 
claim 28. 
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The rejection of claims 41, 47, and 53 Under 35 U.S.C. § 103 

For the convenience of the Honorable Board, claim 41 stands or falls 
together with independent claim 14; claim 47 stands or falls together with 
independent claim 21; and claim 53 stands or falls together with independent claim 
28. 

In view of the foregoing, reversal of the rejections under 35 U.S.C. § 103 is 
respectfully requested. 

Date: July 2, 20 1 1 Respectfully submitted, 

/Steven M. Greenberg/ 
Steven M. Greenberg 
Registration No. 44,725 
Customer Number 46320 
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VIII. CLAIMS APPENDIX 

14. A computer-implemented method for processing contract data associated 
with services to be provided via a network in an infrastructure, in which a plurality 
of binding contracts exists between a service provider and a service requestor for 
services having a respective number of service specifications, the method 
comprising: 

creating said contract data comprising contract selection parameters for 
subsequently selecting at least one service contract out of said plurality of 
contracts; 

including said contract data into a request for said service; 
issuing, via the network, said request for said service; and 
receiving, via the network, the service according to a selection of the at least 
one service contract based upon the contract selection parameters. 

21. A service requester computer server hardware system for processing contract 
data associated with services to be provided via a network in an infrastructure in 
which a plurality of binding contracts exists between a service provider and a 
service requestor for services having a respective number of service specifications, 
the system comprising: 
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at least one processor, wherein the at least one processor configured for 

creating said contract data comprising contract selection parameters 
for subsequently selecting at least one service contract out of said plurality 
of contracts; 

including said contract data into a request for said service; 
issuing said request for said service via network; and 
receiving the service according to a selection of the at least one 
service contract based upon the contract selection parameters. 

28. A computer usable tangible medium having computer readable instructions 
embodied therein for processing contract data associated with services to be 
provided via a network in an infrastructure in which a plurality of binding contracts 
exists between a service provider and a service requestor for services having a 
respective number of service specifications, the computer readable instructions, 
when executed on a computer system, causing the computer system to perform the 
operations comprising: 

creating said contract data comprising contract selection parameters for 
subsequently selecting at least one service contract out of said plurality of 
contracts; 

including said contract data into a request for said service; 
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issuing, via the network, said request for said service; and 
receiving, via the network, the service according to a selection of the at least 
one service contract based upon the contract selection parameters. 

35. A computer-implemented method for processing contract data associated 
with services to be provided via a network in an infrastructure, in which a plurality 
of binding contracts exists between a service provider and a service requestor for 
services having a respective number of service specifications, the method 
comprising: 

receiving, via the network, said contract data included in a request with 
which the service is requested, wherein said contract data comprises contract 
selection parameters for selecting at least one service contract out of said plurality 
of contracts; 

evaluating said contract selection parameters; 

selecting one particular contract according to said evaluation and further 
selection logic; and 

providing, via the network, the service according to said contract. 

36. The method according to claim 14, wherein 
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said contract data is processed via software interfaces adapted to comprise 
said contract data, said interfaces comprising respective definitions of the transport 
protocol in use, of the messaging protocol in use and on an associated port type in 
use. 

37. The method according to claim 14, wherein 

said contract data is processed within header fields of a web service request. 

38. The method according to claim 14, wherein 

said contract data is processed as a part of the endpoint specification of a 
respective service request. 

39. The method according to claim 14, wherein 

said contract selection parameters are transported in a SOAP message 
conforming to the SOAP standard. 

40. The method according to claim 14, wherein 

multiple contract selection parameters are combined in a single service 
request. 
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41 . The method according to claim 14, wherein 

said contract selection parameters comprise meta-data identifying a 
particular contract. 

42. The system according to claim 21, wherein 

said contract data is processed via software interfaces adapted to comprise 
said contract data, said interfaces comprising respective definitions of the transport 
protocol in use, of the messaging protocol in use and on an associated port type in 
use. 

43. The system according to claim 2 1 , wherein 

said contract data is processed within header fields of a web service request. 

44. The system according to claim 21, wherein 

said contract data is processed as a part of the endpoint specification of a 
respective service request. 

45. The system according to claim 21, wherein 

said contract selection parameters are transported in a SOAP message 
conforming to the SOAP standard. 
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46. The system according to claim 21, wherein 

multiple contract selection parameters are combined in a single service 
request. 

47. The system according to claim 21, wherein 

said contract selection parameters comprise meta-data identifying a 
particular contract. 

48. The computer usable tangible medium according to claim 28, wherein 
said contract data is processed via software interfaces adapted to comprise 

said contract data, said interfaces comprising respective definitions of the transport 
protocol in use, of the messaging protocol in use and on an associated port type in 
use. 

49. The computer usable tangible medium according to claim 28, wherein 
said contract data is processed within header fields of a web service request. 

50. The computer usable tangible medium according to claim 28, wherein 
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said contract data is processed as a part of the endpoint specification of a 
respective service request. 

5 1 . The computer usable tangible medium according to claim 28, wherein 
said contract selection parameters are transported in a SOAP message 

conforming to the SOAP standard. 

52. The computer usable tangible medium according to claim 28, wherein 
multiple contract selection parameters are combined in a single service 

request. 

53. The computer usable tangible medium according to claim 28, wherein 
said contract selection parameters comprise meta-data identifying a 

particular contract. 
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IX. EVIDENCE APPENDIX 

No evidence submitted pursuant to 37 C.F.R. §§ 1.130, 1.131, or 1.132 of 
this title or of any other evidence entered by the Examiner has been relied upon by 
Appellant in this Appeal, and thus no evidence is attached hereto. 
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X. RELATED PROCEEDINGS APPENDIX 

Since Appellant is unaware of any related appeals and interferences, no 
decision rendered by a court or the Board is attached hereto. 
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